improve existing code(help appreciated)

Hello,

I would like people to provide feed back regarding attached script.  Is a better way of printing the RTM(<time and memory)?  Any other comments would be appreciated.

Thank you.

-Jim

Re: improve existing code(help appreciated)
llandale - Wed Sep 25 15:54:36 EDT 2013

Didn't study very hard; didn't see anything serious; but have these observations:

• Put the module name, fullName, and Item as global variables.  this will help a tiny bit not having to re-calculate them
• To see if it is open, try if(!open module NameFull).  If the module is closed then handle "m" is corrupted.  Actually, you have a big problem if the module is closed and re-opened while the dialog is waiting.
• Do this to see if anything is in the Buffer: if (length(buf) > 0).
• before "setempty(buf)", do this: "buf = """.  There are times setempty fails which will cause you big headaches.

Did your allocated units checking show a problem?

-Louie

Re: improve existing code(help appreciated)
David_G_Bond - Wed Sep 25 15:55:04 EDT 2013

A really obvious improvement would be to add comments to describe what the script is doing.  This may be clear to you. Now. But in a couple of years when you or someone else needs to update it, the obvious will become obscure.

- David Bond

Re: improve existing code(help appreciated)
llandale - Thu Sep 26 10:31:28 EDT 2013

OK, so I actually ran it and displayed the Dialog.  Like it better.  Got some more thoughts, none serious.

• Dialog title "Show Module Links.." is inadequate.
• Add "; setExtraWidthShare(commandline, 1.0)" after "realize(mainDB)".  I notice the "ON/Off" buttons on the "Settings" tab disappear if you adjust the dialog width.
• Your "Help" button is really "Reg Expression Help" and belongs on the "Filters" tab
• I do not understand the regexp filtering.  Help should have an example
• You need a general "Help" button
• the "Command line" needs explanation.
• The "Linkset pairings" function should be a button, not just upon exit. 
• I would put the buttons below the tab, closer to the selected links to which the buttons apply.
• Seems to me someone using the script will want to go back and browse the module, then back to the dialog.  If so, "block" doesn't work and you would "show" the dialog.  But that will create open-module issues when buttons are pushed.  However, you can auto-close the dialog when the module closes; check out this file, which works well and is actually commented:
  <c:\Program Files\IBM\DOORS\9.3\lib\dxl\utils\moduleDB.inc>
• I must say, that frame inside the tab sure looks good.

Am pushing buttons.  At first I thought this was a "Link" edit dialog but I see it is a "LinkSet" edit dialog.  I'd be tempted to have a "Linkset" listView, which when selected displays the "Links" in the existing listView.  the LinkSet listView could perhaps include all Linkset Pairings as well as existing links.

Looks good.  See no obvious gross ineffeciencies.

-Louie

Re: improve existing code(help appreciated)
EHcnck - Thu Sep 26 17:30:38 EDT 2013

Hello,

Thank you for the feedback attempted to change the block to show but when I did then executed the buttons(Edit, etc.) it would close the dialog..not sure of the correct syntax help would be appreciated.  I rewrote the printRTM rather the using a dialog box I use html..faster results. Is there any way of increase the performance when filling the listview? Thank you.

-Jim

Re: improve existing code(help appreciated)
llandale - Fri Sep 27 11:55:28 EDT 2013

As for "block" vrs "show": Your callbacks generally need to know if it is "show"n or "block"ed.

"show"  Execution ends at "show";  there is no way to get the statement after "show" to execute.  Execitution picks up again in the callbacks.  The close callback should hide and destroy the dialog and cleanup global data structures.  "show"n dialogs have no "release".

"block" Execution after the "block" statement picks up after the code that "releases" the dialog ends.  I believe the following advise is highly desirable, but in any case it is "good": you should "destroy" the dialog only after the "block".  You can clean up your data structures (e.g. delete Skip lists) either after "block" (my advise) or in the close callback (not my advise); but otherwise the close callback should only "release"; must not 'destroy".

Note that function "ack" displays a "block"ed dialog.

I played around "realizing" a dialog without actually "show"ing nor "block"ing it.  IIRC these generally behaved as if they were "shown" but there were a couple obscure cases where it didn't.  Seems to me that the dxl code did not actually officially "end", which only matters if you are doing something obscure.  But I did successfully "realize" one dialog and then "show" or "block" another on top of it.

-Louie

Re: improve existing code(help appreciated)
EHcnck - Mon Jan 20 22:23:32 EST 2014

Hi,

I'm trying to tie my dialog with the module so if you close the module it closes the dialog box. When using "modDB_tie(mainDB)" then changing edit-mode it closes the dialog box using "styleSubWindow" it forces the dialog to be on top of the module is there any way on tying them together with out either closing the dialog box when switching edit-modes or have the dialog on top? Thank you.

//mainDB
// http://www.linkedin.com/groupItem?view=&gid=769057&type=member&item=262141321&qid=571cb717-265e-48a7-a45a-ccc2bc98e21b&trk=groups_items_see_more-0-b-ttl
mainDB = create(current Module, "Show Module Links..." , styleSubWindow|styleCentered)

// https://www.ibm.com/developerworks/community/forums/html/topic?id=0fe02de7-3f6f-4ce1-bc1d-d82297242acf#89f4a396-971a-4f25-bcae-f472e9726c19
//mainDB = create(m, "Show Module Links..." , styleCentered); modDB_tie(mainDB)

Re: improve existing code(help appreciated)
llandale - Tue Jan 21 12:20:06 EST 2014

Looking at modueDB.inc, you can

1. modDB_untie(theDB)
2. Open Edit
3. modDB_tie(theDB, mod)

-Louie